PROCESSOR-SDK-AM65X: eMMC boot

Scott Whitney

Part Number: PROCESSOR-SDK-AM65X
Other Parts Discussed in Thread: AM6548

Hi Forum!

I have a working U-Boot/Linux image that I created with Buildroot. It produces a direct disk image, sdcard.img. I can then install the boot partition and rootfs directly using the following:

sudo dd if=./sdcard.img of=/dev/mmcblk0 bs=1M

In the above example, /dev/mmcblk0 is how my SD card shows up in Ubuntu when I insert it via an adapter card, and can be shown using lsblk.

sdcard.img was created using genimage, and contains a small VFAT partition with sysfw.itb, tiboot3.bin, tispl.bin, u-boot.img, uEnv.txt, Image, and my dtb file. There is also a larger rootfs partition formatted as ext4. For those who have used genimage, here is my genimage.cfg file content:

image boot.vfat {
	vfat {
		files = {
			"sysfw.itb",
			"tiboot3.bin",
			"tispl.bin",
			"u-boot.img",
			"uEnv.txt",
			"Image",
			"k3-am654-reflex3-board.dtb"
		}
	}
	size = 70M
}

image sdcard.img {
	hdimage {
	}

	partition u-boot {
		partition-type = 0xC
		bootable = "true"
        image = "boot.vfat"
	}

	partition rootfs {
		partition-type = 0x83
		image = "rootfs.ext4"
		size = 1G
	}
}

The uSD card is connected to the MMC1 interface. We also have an 8GB eMMC connected to the MMC0 interface on our custom board, and I would like to know how to install the boot and rootfs images onto eMMC, so that I can bypass booting from SD card in the future.

Can anyone provide steps for partitioning, formatting, and booting from eMMC, especially once a working uSD card has been created? Are any changes required to create an image that can boot from eMMC vs. uSD card?

I also know there are bootmode jumpers on the AM6548. Do they have to be modified in order to boot from eMMC instead of uSD card? If so, how should they be set? I'd like to boot from uSD card if it's available, then fall back to booting from eMMC if no uSD card is present.

Thanks for your help, and please let me know if any clarification is needed.

Best regards,

Scott

over 5 years ago

0 Andreas Dannenberg over 5 years ago

TI__Guru 69602 points

Hi Scott,

Scott Whitney80914 said:
Can anyone provide steps for partitioning, formatting, and booting from eMMC, especially once a working uSD card has been created?

Looks like your total image is about 1GB in size. If you have let's say 2GB of RAM in your system you could use U-Boot to load the entire SD card image into RAM, and then from there "burn" it into eMMC. Below are some steps I've used before booting from an SD card that itself is used as an image for eMMC programming, in this case about 700MB. You'll need to update the steps to accommodate for your (larger) image size.

# Set boot mode switches SW3.2, SW3.3, and SW2.3 to ON, all other SW3.x and SW2.x
# set to OFF. Then RESET/power up the board and interrupt boot flow at U-Boot
# prompt.

# Switch to SD card
=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device

# Read the first 704MB (make larger if disk image is larger) to the beginning of DDR
=> mmc read 0x80000000 0 0x160000

MMC read: dev # 1, block # 0, count 1441792 ... 1441792 blocks read: OK

# Switch to eMMC HW boot partition boot1
=> mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device

# Erase entire HW boot partition (8MB == 16384 blocks x 512B/block) to make sure
# ROM doesn't latch onto an eMMC RAW boot mode (assuming eMMC boot mode is on).
=> mmc erase 0 0x4000

# Switch to eMMC UDA partition
=> mmc dev 0 0

# Erase the first 704MB (make larger if disk image is larger) in eMMC UDA
=> mmc erase 0 0x160000

MMC erase: dev # 0, block # 0, count 1441792 ... 1441792 blocks erased: OK

# Write the first 704MB (make larger if disk image is larger) in eMMC UDA
# based on the SD card image we have loaded into UDA
=> mmc write 0x80000000 0 0x160000

Note that you can use similar steps even if your image size is larger than your available memory by doing the copying in chunks. You can also script/automate this for convenience.

Then, to perform the actual boot from eMMC, it would look like this...

# Remove SD card

# Set boot mode switches SW3.2 and SW3.3 to ON, all other SW3.x and SW2.x set
# to OFF. Then RESET/power up the board and interrupt boot flow at U-Boot
# prompt.

# Configure boot partition to point to the eMMC UDA ext4 partition
=> env set bootpart 0:2

# Save U-Boot environment so it persists through RESET (note that the environment
# resides in the eMMC boot HW partition).
=> env save
Saving Environment to MMC... Writing to redundant MMC(0)... OK

# Reset board through U-Boot command and boot to Linux
=> reset
�esetting ...
U-Boot SPL 2019.01-ga280dd38e1 (Aug 30 2019 - 19:04:20 +0000)
SYSFW ABI: 2.6 (firmware rev 0x0013 '19.7.0-v2019.07 (Terrific Llama')
Trying to boot from MMC1
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.1(release):ti2019.02-rc2-149-gce3f151
NOTICE:  BL31: Built : 19:55:20, Jul 31 2019
I/TC: 
I/TC: OP-TEE version: ti2019.02-89-ge5a8779-dev (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 Wed Jul 31 19:55:29 UTC 2019 aarch64
I/TC: Initialized

U-Boot SPL 2019.01-ga280dd38e1 (Aug 30 2019 - 19:04:59 +0000)
detected AM6-IDKAPPEVM
detected SER-PCIE2LEVM
Trying to boot from MMC1


U-Boot 2019.01-ga280dd38e1 (Aug 30 2019 - 19:04:59 +0000)

Model: Texas Instruments AM654 Base Board
DRAM:  4 GiB
MMC:   sdhci@04FA0000 - probe failed: -123
sdhci@4f80000: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
detected AM6-IDKAPPEVM
detected SER-PCIE2LEVM
Net:   eth3: pruss1_eth, eth2: pruss0_eth, eth0: cpsw_nuss@046000000, eth1: pruss2_eth
Hit any key to stop autoboot:  0 
no mmc device at slot 1
SD/MMC found on device 1
13201416 bytes read in 1080 ms (11.7 MiB/s)
72817 bytes read in 2 ms (34.7 MiB/s)
11317 bytes read in 1 ms (10.8 MiB/s)
2084 bytes read in 2 ms (1017.6 KiB/s)
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
   Loading Device Tree to 00000000fddb3000, end 00000000fdec7fff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 4.19.59-g50ceb3c6e7 (oe-user@oe-host) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 SMP PREEMPT Fri Aug 30 19:05:51 UTC 2019
[    0.000000] Machine model: Texas Instruments AM654 Base Board
[    0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
[    0.000000] bootconsole [ns16550a0] enabled
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a0000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a0100000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a1000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a1100000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 512 MiB at 0x00000000c0000000
[    0.000000] psci: probing for conduit method from DT.
<...snip...>

Scott Whitney80914 said:
Are any changes required to create an image that can boot from eMMC vs. uSD card?

You can use an SD card image as-is if programmed into the UDA (User Data Area) of an eMMC, and boot from that, using a mode mode of 0x6 (main bootmode pins).

One "advanced" twist to this: If you wish you could also use eMMC raw boot (bootmode 0x0d) instead and move the bootloader etc. into the eMMC boot1 partition by programming those artifacts in a RAW fashion, which would result in a faster boot time as it would skip the initial ROM-imposed SD card debounce delay applicable to the MMC/SD card boot mode 0x6 recommended earlier. Then, you would load Kernel etc. as usual from the UDA partition. If you are interested in this you can find more info here: https://git.ti.com/cgit/processor-sdk/processor-sdk-u-boot/tree/board/ti/am65x/README?h=processor-sdk-u-boot-2019.01#n213

Scott Whitney80914 said:
I also know there are bootmode jumpers on the AM6548. Do they have to be modified in order to boot from eMMC instead of uSD card? If so, how should they be set? I'd like to boot from uSD card if it's available, then fall back to booting from eMMC if no uSD card is present.

For this I would recommend using boot mode 0x6, meaning setting boot mode switches SW3.2 and SW3.3 to ON, all other SW3.x and SW2.x set to OFF.

Hope that gives you a starting point.

Regards, Andreas

0 Scott Whitney over 5 years ago in reply to Andreas Dannenberg

Expert 1120 points

Hi Andreas,

Thank you for your excellent ideas. I'll certainly try to work through them, but have a couple of complicating factors:

1) The bootmode jumpers are actually resistors that are soldered in place on a custom System-On-Module (SoM) with the AM6548 on it. I will need to look at the details of this board to find out how the bootmode pins are jumpered. I can't easily change them.

2) We only have 512MB of RAM, so I will not be able to read the entire image in at once and program it into the eMMC; it will have to be done in chunks.

At the moment, everything required for booting (including the Linux Image file) is being loaded into the "boot" partition, and is only set to 70MB in size. The rootfs partition is only being set to 1G in size, and we can increase its size later using some Linux partitioning and formatting commands.

Since our current boot partition is so small, is it possible to simply create a VFAT 32 boot partition and ext4 rootfs partition on the eMMC, and then copy everything from the sdcard to the boot partition of the eMMC and reboot? I realize that the U-Boot environment variables may need to be changed to select the correct boot partition from the eMMC.

When I finish booting into Linux, I typed lsblk and noticed that there are a couple of other partitions that appear to be part of the eMMC, mmcblk0boot0 and mmcblk0boot1. Do I need to be concerned with those at all? I confess that I am not sure what those boot partitions are normally used for - I am new to using eMMC.

I appreciate your help, and will try some experiments to see if I can get this to work. I'm not very knowledgeable about the U-Boot commands involved, so this is all a bit of learning curve for me.

Best regards,

Scott

0 Andreas Dannenberg over 5 years ago in reply to Scott Whitney

TI__Guru 69602 points

Hi Scott,

Scott Whitney80914 said:
1) The bootmode jumpers are actually resistors that are soldered in place on a custom System-On-Module (SoM) with the AM6548 on it. I will need to look at the details of this board to find out how the bootmode pins are jumpered. I can't easily change them.

I think you probably want some way at least on the bench to be able to select (at least from a subset of) boot modes to give you more flexibility to recover in case something goes wrong. But it all really depends what your careabouts and constraints are (e.g., how the bootmode pins on your SOM are already pre-wired), but a good understanding of the "BOOTMODE Pin Mapping" in the TRM will be important. Let me know if I can provide some specific advise here.

Scott Whitney80914 said:
2) We only have 512MB of RAM, so I will not be able to read the entire image in at once and program it into the eMMC; it will have to be done in chunks.

Yes.

Scott Whitney80914 said:
The rootfs partition is only being set to 1G in size, and we can increase its size later using some Linux partitioning and formatting commands.

Yes you can re-size a partition in a life system to fill the remaining space, this has been done before many times. One thing to consider however is your system image upgrade strategy in general. Do you want data to persist? How is this being managed? There is an interesting project in this field worth looking into in case you are not aware of it already: https://sbabic.github.io/swupdate/index.html

Scott Whitney80914 said:
Since our current boot partition is so small, is it possible to simply create a VFAT 32 boot partition and ext4 rootfs partition on the eMMC, and then copy everything from the sdcard to the boot partition of the eMMC and reboot? I realize that the U-Boot environment variables may need to be changed to select the correct boot partition from the eMMC.

Yes you could do that. This would also give you more flexibility if you want to want to be able to fully control how to update an existing system.

Scott Whitney80914 said:
When I finish booting into Linux, I typed lsblk and noticed that there are a couple of other partitions that appear to be part of the eMMC, mmcblk0boot0 and mmcblk0boot1. Do I need to be concerned with those at all? I confess that I am not sure what those boot partitions are normally used for - I am new to using eMMC.

eMMC devices usually have two boot partitions called boot1 and boot2 (or mmcblk0boot0 and mmcblk0boot1 as they are often named under Linux). They are extra partitions, usually of fixed size like 8MB, intended to contain a basic bootloader. The eMMC raw boot mode of AM654x for example would expect the bootloader to be programmed into the boot1 partition as outlined earlier. If you don't use eMMC raw boot you don't need to be concerned with the boot partitions usually.

Regards, Andreas

0 Scott Whitney over 5 years ago in reply to Andreas Dannenberg

Expert 1120 points

Hi Andreas,

Here are some results of experiments I ran using your suggestions. I was not able to switch bootmode pins due to physical resistors, but according to the SoM schematic they are set as follows:

7 6 5 4 3 2 1 0

L H L L L H H L

The schematic notes also say Bootmode[0:3] Primary boot source selected - MMC/SD SD CARD, and Bootmode[4:6 Backup boot source selected - MMC/SD EMMC. I have not figured our the bootmode jumpering yet, and have not been able to confirm these resistor settings on the board, but will do so.

After I burn my sdcard.img onto the uSD card, I see the following for mmcblk0 on my Ubuntu laptop:

lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

...
mmcblk0        179:0    0 29.7G 0 disk
├─mmcblk0p1    179:1    0    70M 0 part /media/scwhitn/D80A-62F9
└─mmcblk0p2    179:2    0     1G 0 part /media/scwhitn/b3176cf3-30b1-436f-9de0

So, it looks like I have a 70M boot partition, which contains U-Boot and the Linux image (I believe). If I round that to 100M to be safe, that would be 100 * 1024 * 1024 / 512 = 204800 blocks of 512 bytes each = 0x32000. I then tried to follow your instructions, using 0x32000 instead of your value of 0x160000 blocks:

U-Boot SPL 2019.01 (Nov 08 2019 - 12:49:39 -0500)
SYSFW ABI: 2.6 (firmware rev 0x0013 '19.4.1-v2019.04a (Curious Crow)')
Starting DDR initialization...
Starting DDR training...
LPDDR4 training complete
Completed DDR training
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.1(release):ti2019.01-rc2
NOTICE:  BL31: Built : 04:28:26, Jul  7 2019
I/TC: 
I/TC: OP-TEE version: 3.2.0-583-g251f7c6-dev #1 Sun Jul  7 04:40:43 UTC 2019 aar
ch64
I/TC: Initialized

U-Boot SPL 2019.01 (Nov 08 2019 - 12:56:04 -0500)
Trying to boot from MMC2


U-Boot 2019.01 (Nov 08 2019 - 12:56:04 -0500)

Model: Texas Instruments AM654 Reflex3 Board
DRAM:  512 MiB
MMC:   sdhci@4f80000: 0, sdhci@04FA0000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: cpsw_nuss@046000000 using MAC address from ROM
eth0: cpsw_nuss@046000000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
SD/MMC found on device 1
** Unable to read file boot.scr **
1702 bytes read in 1 ms (1.6 MiB/s)
Loaded env from uEnv.txt
Importing environment from mmc1 ...
Running uenvcmd ...
** Unable to read file .psdk_setup **
## Resetting to default environment
Saving Environment to MMC... Writing to redundant MMC(0)... OK
1 bytes written
�esetting ...
U-Boot SPL 2019.01 (Nov 08 2019 - 12:49:39 -0500)
SYSFW ABI: 2.6 (firmware rev 0x0013 '19.4.1-v2019.04a (Curious Crow)')
Starting DDR initialization...
Starting DDR training...
LPDDR4 training complete
Completed DDR training
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.1(release):ti2019.01-rc2
NOTICE:  BL31: Built : 04:28:26, Jul  7 2019
I/TC: 
I/TC: OP-TEE version: 3.2.0-583-g251f7c6-dev #1 Sun Jul  7 04:40:43 UTC 2019 aar
ch64
I/TC: Initialized

U-Boot SPL 2019.01 (Nov 08 2019 - 12:56:04 -0500)
Trying to boot from MMC2


U-Boot 2019.01 (Nov 08 2019 - 12:56:04 -0500)

Model: Texas Instruments AM654 Reflex3 Board
DRAM:  512 MiB
MMC:   sdhci@4f80000: 0, sdhci@04FA0000: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   
Warning: cpsw_nuss@046000000 using MAC address from ROM
eth0: cpsw_nuss@046000000
Hit any key to stop autoboot:  0 
=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
=> mmc read 0x80000000 0 0x32000

MMC read: dev # 1, block # 0, count 204800 ... 204800 blocks read: OK
=> mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device
=> mmc erase 0 0x4000

MMC erase: dev # 0, block # 0, count 16384 ... 16384 blocks erased: OK
=> mmc dev 0 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc erase 0 0x32000

MMC erase: dev # 0, block # 0, count 204800 ... 204800 blocks erased: OK
=> mmc write 0x80000000 0 0x32000

MMC write: dev # 0, block # 0, count 204800 ... 204800 blocks written: OK
=>

I then removed the SD card and cycled power to try to re-boot. However, I did not get any U-Boot dialog, so I was never able to issue the env set bootpart 0:2 command.

Can you tell what I am doing wrong? Is this because the bootmode jumpers are not correct?

Thanks for your help, and best regards,

Scott

0 Andreas Dannenberg over 5 years ago in reply to Scott Whitney

TI__Guru 69602 points

Hi Scott,

Scott Whitney80914 said:

Here are some results of experiments I ran using your suggestions. I was not able to switch bootmode pins due to physical resistors, but according to the SoM schematic they are set as follows:

7 6 5 4 3 2 1 0

L H L L L H H L

The schematic notes also say Bootmode[0:3] Primary boot source selected - MMC/SD SD CARD, and Bootmode[4:6 Backup boot source selected - MMC/SD EMMC. I have not figured our the bootmode jumpering yet, and have not been able to confirm these resistor settings on the board, but will do so.

Ok. The main boot mode seems to be set to 0x6 which is what you want. Backup boot mode is also set to "MMC/SD" if I read your settings as BOOTMODE[6]=1, BOOTMODE[5]=BOOTMODE[4]=0. The question is, what is BOOTMODE[17] being set/wired(?) to, which controls which MMC interface to use for backup boot. If it is set to 0 then it should probably work for eMMC boot, which might be what your schematic note refers to.

Scott Whitney80914 said:
Can you tell what I am doing wrong? Is this because the bootmode jumpers are not correct?

This could well be. There is a bootmode pin that controls which interface is used for booting if the primary bootmode is 0x6 - pin 12. Please see "Table 4-20. MMC/SD Boot Configuration Fields" in the AM654x TRM. When this bit is 0 it would boot from eMMC in your case, and when this bit is 1 it boots from SD card. Can you check how this pin is wired on your EVM, and if you can control it? It may also be possible you set BOOTMODE[7] to 1 which you seem to have control over, this way activating the "minimum" settings for the primary boot mode, which should give you filesystem-based boot from your eMMC at port 0 according to table 4-20 "MIN Default" column.

If you can tell me exactly what all your bootmode pins are set to and which ones are under your control I can give some more specific advise.

Regards, Andreas

0 Mohsen Khayami over 5 years ago in reply to Andreas Dannenberg

TI__Mastermind 22391 points

Hi Scott

I suggest you read the emmc before you boot the system with the below command.

fatls mmc 0:1 that way you can make sure that the u-boot and the other 3 files are in the first sector. The linux image is part of the file system. Also you can read the file system just to make sure it was copied correctly by the below command.

ext2ls mmc 0:2 if you see all the directories then you have all the files correct on the system.

Regards

Mohsen

0 Mohsen Khayami over 5 years ago in reply to Mohsen Khayami

TI__Mastermind 22391 points

Hi Scott

Also the problem is that you have to read the full 1.07G that way you get the correct file system on the EMMC. I am trying to see how to make this work on the system hopefully by tomorrow.

Thanks

Mohsen

0 Scott Whitney over 5 years ago in reply to Mohsen Khayami

Expert 1120 points

Thanks for the clarification, Mohsen. Looking forward to receiving more info from you.

Many thanks for the help, and best regards,

Scott

0 Scott Whitney over 5 years ago in reply to Andreas Dannenberg

Expert 1120 points

Hi Andreas,

Looking at the SoM schematic, here are the default bootmode pin settings:

18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

H L L NC NC L H L L H L L H L L L H H L

These are hard-wired with pullup or pulldown resistors, not switches. I am not sure why 15 and 14 were left as no-connects, but do not know the bootmode settings well.

You had mentioned BOOTMODE[17], which does look like it is strapped low.

Is there any way to read the bootmode pins from a register to confirm what the schematic is telling me?

Hoping this gives you more information about what steps I should take to go from my SD card image to an image that will boot from eMMC. If I have to change resistor values, it's going to be painful, but so be it!

Thanks and best regards,

Scott

0 Andreas Dannenberg over 5 years ago in reply to Scott Whitney

TI__Guru 69602 points

Scott,

Scott Whitney80914 said:
Is there any way to read the bootmode pins from a register to confirm what the schematic is telling me?

You can read the bootmode pins by looking at the CTRLMMR_MAIN_DEVSTAT control register, just like U-Boot does. You can access its contents from the U-Boot console as follows. First example shows my AM654x EVM booting from SD card, explicitly configured for that mode:

=> md
md - memory display

Usage:
md [.b, .w, .l, .q] address [# of objects]
=> md 0x00100030 1
00100030: 00001006                               ....

Now, second example, I'm performing a file-system based boot from the eMMC user data area (UDA), that contains the two partitions as discussed earlier. Also, explicitly configured for that mode.

=> md 0x00100030 1
00100030: 00000006 ....

You can see that it is still using bootmode 0x6, but now bit 12 is turned off, which moves the MMC controller "port" from 1 to 0.

Note that you can't change those switches during runtime and expect U-Boot to show you new values; the contents of register CTRLMMR_MAIN_DEVSTAT is latched from the pins at reset time.

Scott Whitney80914 said:
These are hard-wired with pullup or pulldown resistors, not switches. I am not sure why 15 and 14 were left as no-connects, but do not know the bootmode settings well.

If you look at the AM654x TRM "Table 4-10. Primary Boot Mode Configuration" you see that those pins are a don't care so that's why they probably have been left unconnected, although one could argue that leaving those pins unconnected might not be a good idea (floating CMOS input? Should double-check against data manual the actual pin configuration).

Scott Whitney80914 said:

18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

H L L NC NC L H L L H L L H L L L H H L

You pin 12 is tied high which means port 1 is always used for primary boot.

Your pin 17 is tied low which means port 0 is used for backup boot, which is what we want.

So I just tried out your exact configuration for both eMMC-based boot from MMC0 and SD-card based boot from MMC1 on the AM654x EVM as follows. With the SD card inserted I could boot from SD card without issues. With the SD card removed I could boot from eMMC without issues (via backup boot mode). All with no change in boot mode pins. So it sounds like the configuration performs as you need it.

For reference, the boot mode pins are read back by the SoC as shown below. Can you please boot from SD card and cross-check, you should get the same, which also should match what you read from the schematics:

=> md 0x00100030 1
00100030: 00041246                               F...

If that's the case that means your boot mode pins are not the issue here, but possibly the way you program the eMMC module.

Regards, Andreas

0 Scott Whitney over 5 years ago in reply to Andreas Dannenberg

Expert 1120 points

Hi Andreas,

Thank you for your detailed reply. I ran the command you suggested from the U-Boot prompt, and I am seeing the following:

=> md 0x00100030 1
00100030: 00047f46                               F...

Comparing with your output, it seems like there are differences in bits 8, 10, 11, 13, and 14. These values do not seem to match up with the resistive strapping that I see on the schematic. I may need to look at this more closely under a microscope to see what has actually been installed for pullups/pulldowns.

That aside, pin 12 is indeed high, and pin 17 is low. Does that imply that we should be able to boot from SD card as the primary, and eMMC via backup? Or does this value indicate other problems with the bootmode jumpers and operation?

Once I am certain of the actual bootmode pin wiring, I will need some help in reading blocks that will fit into our 512MB RAM and writing them out to the appropriate areas of the eMMC. Can you provide a sequence of steps to do this that will write the entire ~1.07GB of our image data, as Mohsen suggested?

Thank you very much again for your diligence!

Scott

0 Andreas Dannenberg over 5 years ago in reply to Scott Whitney

TI__Guru 69602 points

Scott,

Scott Whitney80914 said:
That aside, pin 12 is indeed high, and pin 17 is low. Does that imply that we should be able to boot from SD card as the primary, and eMMC via backup? Or does this value indicate other problems with the bootmode jumpers and operation?

Yes pin 12 and pin 17 are good. I was using a CTRLMMR_MAIN_DEVSTAT configuration of 0x00041246 as outlined earlier to do just that. SD card boot from MMC1 with fallback to eMMC boot from MMC0.

Scott Whitney80914 said:
Thank you for your detailed reply. I ran the command you suggested from the U-Boot prompt, and I am seeing the following:
=> md 0x00100030 1
00100030: 00047f46                               F...

I just tried those boot mode settings locally on the AM654x EVM, and those work as well, both primary boot via SD card and fall-back via eMMC. It still doesn't explain though why this value doesn't match the pin strapping you read from the schematic. Are these pins getting loaded by some other circuitry?

=> md 0x00100030 1
00100030: 00047f46                               F...

Scott Whitney80914 said:
Once I am certain of the actual bootmode pin wiring, I will need some help in reading blocks that will fit into our 512MB RAM and writing them out to the appropriate areas of the eMMC. Can you provide a sequence of steps to do this that will write the entire ~1.07GB of our image data, as Mohsen suggested

Let me double-check the steps you provided earlier first. We need to get the basic bootloader to work from the fat partition. Can you do the basic fatls command when booted from SD card to check the eMMC contents like this:

=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> fatls mmc 0:1
   266050   sysfw.itb
   139316   tiboot3.bin
   534852   tispl.bin
   948460   u-boot.img

4 file(s), 0 dir(s)

=>

Regards, Andreas

0 Mohsen Khayami over 5 years ago in reply to Andreas Dannenberg

TI__Mastermind 22391 points

Hi Scott

i just got the EVM to boot from the EMMC. The thing i had to do is use the tisdk-docker-rootfs-image-am65xx-evm.tar.xz which comes with the PSDK release. It is a lot smaller file system. The command I used are below.

The file system size is around 575MB and the root directory is around 70.4MB. You need to add those up and give your self some extra space also. I used a bigger size just in case.

mmc dev 1

mmc read 0x80000000 0 0x170000

mmc dev 0 1

mmc erase 0 0x4000

mmc dev 0 0

mmc erase 0 0x170000

mmc write 0x80000000 0

setenv bootpart 0:2

saveenv

Turn off the board and then remove the SD card. Then power the board and it should boot from the emmc. The only thing to keep in mind is that it will take a little time because the EMMC is the secondary boot so it has to check the primary boot device which is the SD card.

0 Scott Whitney over 5 years ago in reply to Mohsen Khayami

Expert 1120 points

This is very helpful, Mohsen and Andreas,

However, we only have 512MB of LPDDR4 memory. Can either of you provide an example of how to read/write the eMMC in "chunks" that will fit into the available RAM?

Many thanks!

Scott

0 Mohsen Khayami over 5 years ago in reply to Scott Whitney

TI__Mastermind 22391 points

Hi Scott

working on it...

0 Mohsen Khayami over 5 years ago in reply to Mohsen Khayami

TI__Mastermind 22391 points

Hi Scott

I just did and it worked for me. What you have to do is break the read and the write into multiple times. The erase can be done in one time.

For my case I did the read from block 0 and the size is 0xb0000 and then did the EMMC write to block 0 and the size is 0xb0000. Then I read the block from 0xb0000 and the size is 0xc0000 because my total read was 0x170000 (0xb0000 + 0xc0000 = 0x170000). Then did the write to the EMMC starting at block 0xb0000 and the size is 0xc0000.

mmc dev 1 //Change to sd card

mmc read 0x80000000 0 0xb0000 //read the first 0xb0000

mmc dev 0 1

mmc erase 0 0x4000

mmc dev 0 0 //change to EMMC

mmc erase 0 0x170000 //erase the total block you need

mmc write 0x80000000 0 0xb0000 // write the first 0xb0000

mmc dev 1 //Change to sd card

mmc read 0x80000000 0xb0000 0xc0000 //read from 0xb0000 and the count is 0xc0000 so total 0x170000

mmc dev 0 0

mmc write 0x80000000 0xb0000 0xc0000 //write the last 0xc0000

setenv bootpart 0:2

saveenv

power off then take the SD card out and power up.

0 Andreas Dannenberg over 5 years ago in reply to Scott Whitney

TI__Guru 69602 points

Scott,

Scott Whitney80914 said:
This is very helpful, Mohsen and Andreas,

you were battling issues with basic eMMC boot last time I checked, not even getting any bootloader prints. Where you able to resolve this aspect?

Regards, Andreas

0 Scott Whitney over 5 years ago in reply to Andreas Dannenberg

Expert 1120 points

Hi Andreas,

You are correct, and I have still not gotten to basic eMMC bootloader prompts yet. However, I have been swamped pursuing other higher-priority activities, and it's possible that the suggestions and information that you and Mohsen have provided will get me past this issue.

If I continue to run into trouble, I will try working with Mohsen locally, and can also post questions and information back to this thread.

Thanks for your diligence in following up on this for us!

Best regards,

Scott

Processors

Processors forum

PROCESSOR-SDK-AM65X: eMMC boot